Cookie Invalidation Or Expiration By A Switch

ABSTRACT

A switch may be used to force the expiration of a cookie on a user&#39;s system by inserting an expiration field into the cookie contained in a network response packet. Additionally, a mechanism is provided to delete or damage a cookie contained in a network request packet, so that server software is not disrupted by the receipt of a cookie. Deleting a cookie results in a cleaner request, but damaging a cookie may be more efficient in certain circumstances. By providing these features, an efficient cookie switching design is provided.

CROSS-REFERENCE TO RELATED APPLICATION

The present application is a continuation of application Ser. No.12/961,438, filed on Dec. 6, 2010, which is a continuation ofapplication Ser. No. 12/760,545, filed on Apr. 14, 2010, now U.S. Pat.No. 7,877,491, which is a continuation of application Ser. No.10/364,892, filed on Feb. 11, 2003, entitled “COOKIE INVALIDATION OREXPIRATION BY A SWITCH,” now U.S. Pat. No. 7,720,977, in the name of thesame inventor and commonly owned herewith.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent files or records, but otherwise reserves all copyrightrights whatsoever.

FIELD OF THE INVENTION

The present invention relates to the field of switching in a computernetwork. More particularly, the present invention relates to theinvalidation or expiration of cookies by a switch in a computer network.

BACKGROUND OF THE INVENTION

Due to increased traffic on the Internet, many web sites now comprise aseries of redundant servers controlled by a switch. FIG. 1 is a diagramillustrating an example of a computer network with redundant servers.The plurality of redundant servers 104 a-104 e are managed by a switch102, which may direct traffic from a user 100 to an appropriate serverbased on various Quality of Service (QoS) parameters. For example, theswitch 102 may perform load balancing, where traffic is directed toservers that are best able to handle the bandwidth and processor loadrequired at the time the traffic is received.

In certain circumstances, however, it is beneficial to route trafficfrom a single user to the same server or server group each time atransaction (which may include a request and a response) is made.Normally, however, the traffic is routed based solely on the currentserver load. One solution to this would be to examine the source of thetraffic (i.e., the user's IP address) and use that information to routethe traffic to the same server or server group as was used in the lasttransmission.

Unfortunately, it is not always possible to distinguish individual usersby their IP address, such as where network address translation is used(NAT). For these cases, it may be helpful to utilize cookies to identifyindividual users. When a client makes a request from a server, theresponse from the server can contain a cookie embedded into theHypertext Transport Protocol (HTTP) header of the response. The clientmay then store the cookie and, upon subsequent requests, place thecookie into the HTTP header of the request. The server may then performcookie switching for any HTTP request containing a cookie, routing therequest to an appropriate server identified by the cookie.

Some companies, however, would need to significantly alter the softwarecode running on their servers in order to provide for the ability togenerate cookies. For these companies, a solution wherein the switchitself generated the cookies would be more beneficial. In thisimplementation, the switch would introduce a cookie to the HTTP responsewhen it receives it, before forwarding it back to the user. Eachincoming HTTP request would be examined to determine if a valid cookieidentifies a preferred server for routing, and route the requestaccordingly.

Several problems, however, are introduced by such an implementation.First, it may sometimes be necessary for a particular cookie to bedeleted from the user's computer, for example if the correspondingserver is down or has been removed from the system. However, currentlyno mechanism exists allowing the switch to indicate that a cookie shouldbe deleted from the user's computer. Furthermore, some companies mayhave software that is incompatible with cookies, even to such an extentas to crash or otherwise interfere with the performance of the softwareif an http request is received containing a cookie, even if the softwareis not planning on doing anything with the cookie. Currently, nomechanism exists for removing the cookie before it arrives at such acompany's server. Therefore, a need exists for a solution that canovercome these problems.

BRIEF DESCRIPTION OF THE INVENTION

A switch may be used to force the expiration of a cookie on a user'ssystem by inserting an expiration field into the cookie contained in anetwork response packet. Additionally, a mechanism is provided to deleteor damage a cookie contained in a network request packet, so that serversoftware is not disrupted by the receipt of a cookie. Deleting a cookieresults in a cleaner request, but damaging a cookie may be moreefficient in certain circumstances. By providing these features, anefficient cookie switching design is provided.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated into and constitute apart of this specification, illustrate one or more embodiments of thepresent invention and, together with the detailed description, serve toexplain the principles and implementations of the invention.

In the drawings:

FIG. 1 is a diagram illustrating an example of a computer network withredundant servers.

FIG. 2 is a flow diagram illustrating a method for adding a cookie to anetwork response packet at a switch in accordance with an embodiment ofthe present invention.

FIG. 3 is a flow diagram illustrating a method for invalidating a cookiefrom a network request packet at a switch in accordance with anembodiment of the present invention.

FIG. 4 is a block diagram illustrating a switch for adding a cookie to anetwork response packet at a switch in accordance with an embodiment ofthe present invention.

FIG. 5 is a block diagram illustrating a switch capable of invalidatinga cookie from a network request packet at a switch in accordance with anembodiment of the present invention.

DETAILED DESCRIPTION

Embodiments of the present invention are described herein in the contextof a system of computers, servers, and software. Those of ordinary skillin the art will realize that the following detailed description of thepresent invention is illustrative only and is not intended to be in anyway limiting. Other embodiments of the present invention will readilysuggest themselves to such skilled persons having the benefit of thisdisclosure. Reference will now be made in detail to implementations ofthe present invention as illustrated in the accompanying drawings. Thesame reference indicators will be used throughout the drawings and thefollowing detailed description to refer to the same or like parts.

In the interest of clarity, not all of the routine features of theimplementations described herein are shown and described. It will, ofcourse, be appreciated that in the development of any such actualimplementation, numerous implementation-specific decisions must be madein order to achieve the developer's specific goals, such as compliancewith application- and business-related constraints, and that thesespecific goals will vary from one implementation to another and from onedeveloper to another. Moreover, it will be appreciated that such adevelopment effort might be complex and time-consuming, but wouldnevertheless be a routine undertaking of engineering for those ofordinary skill in the art having the benefit of this disclosure.

In accordance with the present invention, the components, process steps,and/or data structures may be implemented using various types ofoperating systems, computing platforms, computer programs, and/orgeneral purpose machines. In addition, those of ordinary skill in theart will recognize that devices of a less general purpose nature, suchas hardwired devices, field programmable gate arrays (FPGAs),application specific integrated circuits (ASICs), or the like, may alsobe used without departing from the scope and spirit of the inventiveconcepts disclosed herein. Furthermore, the present invention isdescribed in the context of a switch. However, one of ordinary skill inthe art will recognize that the term switch should be read broadly, soas to include any device that directs packets, including a router and agateway.

The present invention provides a mechanism for a switch to force theexpiration of a cookie on a user's system. Additionally, a mechanism isprovided to delete or damage a cookie contained in a request, so thatserver software is not disrupted by the receipt of a cookie. Deleting acookie results in a cleaner request, but damaging a cookie may be moreefficient in certain circumstances. By providing these features, thepresent invention allows for a robust and efficient cookie switchingdesign. Furthermore, the invention may be expanded to invalidate anyportions of the header other than the cookie, should the need arise.

In an embodiment of the present invention, an extra field may be addedto a cookie in an http response indicating when it should expire. Thismay be helpful for two reasons. First, this allows for a switch havingknowledge that a server will be going down (for example, for scheduledmaintenance) or removed to provide for a timing mechanism wherein thecookie continues to function until a predetermined time arrives. Second,this allows for a switch to force the immediate deletion of an existingcookie on the user's system. In the second case, the switch need onlytransmit an empty cookie but having an expiration time that has alreadybeen reached.

Thus, a corresponding cookie may appear as follows:

Cookie: FoundryFoo=; path=/; domain=www.foundrynet.com; expires=Tue,01-Jan- 1980 00:00:00 GMT

This cookie indicates that the cookie “FoundryFoo”, which is valid forall paths within domain www.foundrynet.com, will be expired immediatelyfrom both the memory and the hard drive on the user's system. By settingthe cookie to empty, the cookie may be invalidated during the currentbrowser session of the user. Typically, the cookie expiration time wouldonly be examined upon the beginning or ending of a browser session, thusmerely setting the expiration time to a past time may not immediatelyinvalidate the cookie.

In another embodiment of the present invention, a global clock may besupported for this expiration time. For purposes of this application,global clock should be construed as meaning any clock not controlled bythe device performing the specified act (i.e. the switch, or the user'ssystem). This provides much more accuracy than using local clocks, whichcan potentially have significant time variations from one system to thenext. For example, a network time protocol server (NTP) may be providedwhich may interface with both the switch and the user's system. One ofordinary skill in the art will recognize that NTP may be embodied inseveral different ways using many different devices, and that it ispossible to communicate via NTP without actually communicating directlywith an NTP server.

Removal of a cookie in a request may be accomplished in two differentways. In one embodiment, the cookie may actually be deleted from therequest. Here, for example, a single cookie is deleted by deleting theentire cookie header:

Cookie: FoundryFoo=1234\r\n gets entirely deleted.

For more complicated cases where the cookie to be deleted is only one ofa number of cookies in a cookie header, the switch should locate onlythe appropriate cookie to delete, lest valuable information be lost. Forexample:

Cookie: Address=Washington; FoundryFood=1234; name=Mike\r\n

may become:

Cookie: Address=Washington; name=Mike\r\n

One potential problem with cookie deletion, however, is that fulldeletion gives rise to the possibility that the full checksum of thepacket needs to be recalculated due to the change in the packet length.Therefore, it may be beneficial in certain circumstance to damage thecookie without deleting it. In an embodiment of the present invention,damaging the cookie may be performed by swapping four bytes of thecookie name (or cookie header name if there is only a single cookie inthe header). This can be more efficient since it invalidates the cookiewithout having to change the packet size and recalculate the checksum.It will often be the first four bytes of the cookie name or cookieheader name being swapped. However, if the first byte of the cookie nameof cookie header name is not an even byte from the start of the packet,it may be more efficient to swap the second to fifth bytes rather thanthe first to fourth. This is because checksums are typically calculatedby looking at every two bytes of data in the packet and calculating avalue based on those two bytes, then adding it to a value for the nexttwo bytes, etc. If the bytes to be swapped do not start on an even byte,the checksum calculation may be incorrect.

The four bytes may be swapped by swapping the first of the four byteswith the second of the four bytes, and the third with the fourth. Asdescribed above, this allows the data to be modified without affectingthe checksums. Thus, in an example with only one cookie:

Cookie: FoundryFoo=1234\r\n

then the cookie header name may be damaged to read:

okCoie: FoundryFoo=1234\r\n

For an example with multiple cookies:

Cookie: Address=Washington; FoundryFoo=1234; name=Mike\r\n

then the cookie name may be damaged to read:

Cookie: Address=Washington; unFodryFoo=1234; name=Mike\r\n

If, however, in the first example above, the cookie header name beginson an odd byte, then the second through fifth bytes are the ones thatwill be affected. Thus:

Cookie: FoundryFoo=1234\r\n

would be damaged to read:

Ckiooe: FoundryFoo=1234 \r\n

FIG. 2 is a flow diagram illustrating a method for adding a cookie to anetwork response packet at a switch in accordance with an embodiment ofthe present invention. At 200, a local clock may be synchronized with aglobal clock. The global clock may be a Network Time Protocol (NTP)clock, which may interface with the switch and a user's system, althoughthat is not essential. The synchronization may be performedperiodically. At 202, an expiration field may be inserted into thecookie, the expiration field indicating a time when the cookie shouldexpire according to the local clock. The expiration field may indicate atime that has already passed if it is desired that a previously storedcookie on the user's system be invalidated immediately, although that isnot essential. Additionally, a cookie value for the cookie may be emptyif it is desired that a previously stored cookie on the user's system beinvalidated, although that is not essential. At 204, the cookie may beplaced into the network response packet. At 206, the network responsepacket may be forwarded to the user's system. In an embodiment of thepresent invention, the expiration time to be inserted is recalculatedevery 20 seconds rather than per each network response packet. Thisavoids thousands of calculations of the expiration time.

FIG. 3 is a flow diagram illustrating a method for invalidating a cookiefrom a network request packet at a switch in accordance with anembodiment of the present invention. At 300, it is determined if thecookie is the only cookie in a cookie header in the network requestpacket or if the cookie is only one of a plurality of cookies in thenetwork request packet. If it is the only cookie in a cookie header inthe network request packet, at 302 it is determined if a cookie headername begins at an even byte or an odd byte from a beginning point of theheader of the network request packet. If it is an even byte, then at 304a first odd byte/even byte pair of the cookie header name may be swappedwith a second odd byte/even byte pair of the cookie header name. If itis an odd byte, then at 306 a first even byte/odd byte pair of thecookie header name may be swapped with a second even byte/odd byte pairof the cookie header name. An odd byte/even byte pair is an odd bytefollowed by an even byte, while an even byte/odd byte pair is an evenbyte followed by an odd byte. In an embodiment of the present invention,the first odd byte/even byte pair may be the first and second bytes fromthe beginning of the cookie header name, while the second odd byte/evenbyte pair may be the third and fourth bytes. Additionally, the firsteven byte/odd byte pair may be the second and third bytes from thebeginning of the cookie header name, while the second even byte/odd bytepair may be the fourth and fifth bytes.

If, on the other hand, the cookie is one of a plurality of cookies inthe network request packet, then at 308 it is determined if a cookiename corresponding to the cookie begins at an even byte or an odd bytefrom a beginning point of the header of the network request packet. Ifit is an even byte, then at 310 a first odd byte/even byte pair of thecookie name may be swapped with a second odd byte/even byte pair of thecookie name. If it is an odd byte, then at 312 a first even byte/oddbyte pair of the cookie name may be swapped with a second even byte/oddbyte pair of the cookie name. An odd byte/even byte pair is an odd bytefollowed by an even byte, while an even byte/odd byte pair is an evenbyte followed by an odd byte. In an embodiment of the present invention,the first odd byte/even byte pair may be the first and second bytes fromthe beginning of the cookie name, while the second odd byte/even bytepair may be the third and fourth bytes. Additionally, the first evenbyte/odd byte pair may be the second and third bytes from the beginningof the cookie name, while the second even byte/odd byte pair may be thefourth and fifth bytes.

While it is not essential, the method may only be performed for networkrequest packets to be routed to a particular server and wherein theparticular server is registered as not wanting to receive the cookie.

FIG. 4 is a block diagram illustrating a switch for adding a cookie to anetwork response packet at a switch in accordance with an embodiment ofthe present invention. A local clock-to-global clock synchronizer 400may synchronize a local clock with a global clock. The global clock maybe a Network Time Protocol (NTP) clock, which may interface with theswitch and a user's system, although that is not essential. Thesynchronization may be performed periodically. A cookie expiration fieldinserter 402 coupled to the local clock-to-global clock synchronizer 400may insert an expiration field into the cookie, the expiration fieldindicating a time when the cookie should expire according to the localclock of the user. The expiration field may indicate a time that hasalready passed if it is desired that a previously stored cookie on theuser's system be invalidated, although that is not essential.Additionally, a cookie value for the cookie may be empty if it isdesired that a previously stored cookie on the user's system beinvalidated, although that is not essential. A cookie-to-networkresponse packet placer 404 coupled to the cookie expiration fieldinserter 402 may place the cookie in a cookie header in the networkresponse packet. A network response packet forwarder 406 coupled to thecookie-to-network response packet placer 404 may forward the networkresponse packet may be forwarded to the user's system. In an embodimentof the present invention, the expiration time to be inserted isrecalculated every 20 seconds rather than per each network responsepacket. This avoids thousands of calculations of the expiration time.

FIG. 5 is a block diagram illustrating a switch capable of invalidatinga cookie from a network request packet at a switch in accordance with anembodiment of the present invention. A lone cookie determiner 500 maydetermine if the cookie is the only cookie in a cookie header in thenetwork request packet or if the cookie is only one of a plurality ofcookies in the network request packet. If it is the only cookie in acookie header in the network request packet, a cookie header name evenbyte determiner 502 coupled to the lone cookie determiner 500 maydetermine if a cookie header name begins at an even byte or an odd bytefrom a beginning point of the network request packet. If it is an evenbyte, then a first odd byte/even byte pair-to-second odd byte/even bytepair cookie header name swapper 504 coupled to the cookie header nameeven byte determiner 502 may swap a first odd byte/even byte pair of thecookie header name with a second odd byte/even byte pair of the cookieheader name. If it is an odd byte, then a first even byte/odd bytepair-to-second even byte/odd byte pair cookie header name swapper 506coupled to the cookie header name even byte determiner 502 may swap afirst even byte/odd byte pair of the cookie header name with a secondeven byte/odd byte pair of the cookie header name. An odd byte/even bytepair is an odd byte followed by an even byte, while an even byte/oddbyte pair is an even byte followed by an odd byte. In an embodiment ofthe present invention, the first odd byte/even byte pair may be thefirst and second bytes from the beginning of the cookie header name,while the second odd byte/even byte pair may be the third and fourthbytes. Additionally, the first even byte/odd byte pair may be the secondand third bytes from the beginning of the cookie header name, while thesecond even byte/odd byte pair may be the fourth and fifth bytes.

If, on the other hand, the cookie is one of a plurality of cookies inthe network request packet, then a cookie name even byte determiner 508coupled to the lone cookie determiner 500 may determine if a cookie namecorresponding to the cookie begins at an even byte or an odd byte from abeginning point of the network request packet. If it is an even byte,then a first odd byte/even byte pair-to-second odd byte/even byte paircookie name swapper 510 coupled to the cookie name even byte determiner508 may swap a first odd byte/even byte pair of the cookie name with asecond odd byte/even byte pair of the cookie name. If it is an odd byte,then a first even byte/odd byte pair-to-second even byte/odd byte paircookie name swapper 512 coupled to the cookie name even byte determiner508 may swap a first even byte/odd byte pair of the cookie name with asecond even byte/odd byte pair of the cookie name. An odd byte/even bytepair is an odd byte followed by an even byte, while an even byte/oddbyte pair is an even byte followed by an odd byte. In an embodiment ofthe present invention, the first odd byte/even byte pair may be thefirst and second bytes from the beginning of the cookie name, while thesecond odd byte/even byte pair may be the third and fourth bytes.Additionally, the first even byte/odd byte pair may be the second andthird bytes from the beginning of the cookie name, while the second evenbyte/odd byte pair may be the fourth and fifth bytes.

While embodiments and applications of this invention have been shown anddescribed, it would be apparent to those skilled in the art having thebenefit of this disclosure that many more modifications than mentionedabove are possible without departing from the inventive concepts herein.The invention, therefore, is not to be restricted except in the spiritof the appended claims.

What is claimed is:
 1. A method comprising: at a network deviceconfigured to perform packet switching, swapping a first odd byte/evenbyte pair of a cookie header name with a second odd byte/even byte pairof the cookie header name if the cookie header name begins at an evenbyte from a beginning point of a header of a network request packet; andswapping a first even byte/odd byte pair of the cookie header name witha second even byte/odd byte pair of the cookie header name if the cookieheader name begins at an odd byte from a beginning point of the headerof the network request packet.
 2. The method of claim 1, wherein an oddbyte/even byte pair is an odd byte followed by an even byte.
 3. Themethod of claim 1, wherein an even byte/odd byte pair is an even bytefollowed by an odd byte.
 4. The method of claim 1, wherein the method isonly performed for network request packets to be routed to a particularserver and wherein the particular server is registered as not wanting toreceive the cookie.
 5. A method comprising: at a network deviceconfigured to perform packet switching, swapping a first odd byte/evenbyte pair of a cookie name with a second odd byte/even byte pair of thecookie name if the cookie name begins at an even byte from a beginningpoint of a header of a network request packet; and swapping a first evenbyte/odd byte pair of the cookie name with a second even byte/odd bytepair of the cookie name if the cookie name begins at an odd byte from abeginning point of the header of the network request packet.
 6. Themethod of claim 5, wherein an odd byte/even byte pair is an odd bytefollowed by an even byte.
 7. The method of claim 5, wherein an evenbyte/odd byte pair is an even byte followed by an odd byte.
 8. Themethod of claim 5, wherein the method is only performed for networkrequest packets to be routed to a particular server and wherein theparticular server is registered as not wanting to receive the cookie. 9.A method comprising: at a network switch configured to perform packetswitching, swapping a first odd byte/even byte pair of a cookie headername with a second odd byte/even byte pair of the cookie header name ifthe cookie header name begins at an even byte from a beginning point ofa header of a network request packet and if the cookie is an only cookiein a cookie header in the network request packet; swapping a first evenbyte/odd byte pair of the cookie header name with a second even byte/oddbyte pair of the cookie header name if the cookie header name begins atan odd byte from a beginning point of the header of the network requestpacket and if the cookie is the only cookie in a cookie header in thenetwork request packet; swapping a first odd byte/even byte pair of thecookie name with a second odd byte/even byte pair of the cookie name ifthe cookie name begins at an even byte from a beginning point of theheader of the network request packet and if the cookie is one of aplurality of cookies in the network request packet; and swapping a firsteven byte/odd byte pair of the cookie name with a second even byte/oddbyte pair of the cookie name if the cookie name begins at an odd bytefrom a beginning point of the header of the network request packet andif the cookie is one of a plurality of cookies in the network requestpacket.
 10. The method of claim 9, wherein an odd byte/even byte pair isan odd byte followed by an even byte.
 11. The method of claim 9, whereinan even byte/odd byte pair is an even byte followed by an odd byte. 12.The method of claim 9, wherein the method is only performed for networkrequest packets to be routed to a particular server and wherein theparticular server is registered as not wanting to receive the cookie.13. A method comprising: at a network device configured to performpacket switching, swapping a first odd byte/even byte pair of a headername with a second odd byte/even byte pair of the header name if theheader name begins at an even byte from a beginning point of a header ofa network packet; and swapping a first even byte/odd byte pair of theheader name with a second even byte/odd byte pair of the header name ifthe header name begins at an odd byte from a beginning point of theheader of the network packet.
 14. The method of claim 13, wherein an oddbyte/even byte pair is an odd byte followed by an even byte.
 15. Themethod of claim 13, wherein an even byte/odd byte pair is an even bytefollowed by an odd byte.
 16. An apparatus comprising: a memory; and oneor more processors configured to: swap a first odd byte/even byte pairof a cookie header name with a second odd byte/even byte pair of thecookie header name if the cookie header name begins at an even byte froma beginning point of a header of a network request packet; and swap afirst even byte/odd byte pair of the cookie header name with a secondeven byte/odd byte pair of the cookie header name if the cookie headername begins at an odd byte from a beginning point of the header of thenetwork request packet.
 17. An apparatus comprising: a memory; and oneor more processors configured to: swap a first odd byte/even byte pairof a cookie name with a second odd byte/even byte pair of the cookiename if the cookie name begins at an even byte from a beginning point ofa header of a network request packet; and swap a first even byte/oddbyte pair of the cookie name with a second even byte/odd byte pair ofthe cookie name if the cookie name begins at an odd byte from abeginning point of the header of the network request packet.
 18. Anapparatus comprising: a memory; and one or more processors configuredto: swap a first odd byte/even byte pair of a cookie header name with asecond odd byte/even byte pair of the cookie header name if the cookieheader name begins at an even byte from a beginning point of a header ofa network request packet and if the cookie is an only cookie in a cookieheader in the network request packet; swap a first even byte/odd bytepair of the cookie header name with a second even byte/odd byte pair ofthe cookie header name if the cookie header name begins at an odd bytefrom a beginning point of the header of the network request packet andif the cookie is the only cookie in a cookie header in the networkrequest packet; swap a first odd byte/even byte pair of the cookie namewith a second odd byte/even byte pair of the cookie name if the cookiename begins at an even byte from a beginning point of the header of thenetwork request packet and if the cookie is one of a plurality ofcookies in the network request packet; and swap a first even byte/oddbyte pair of the cookie name with a second even byte/odd byte pair ofthe cookie name if the cookie name begins at an odd byte from abeginning point of the header of the network request packet and if thecookie is one of a plurality of cookies in the network request packet.